Many electronic commerce systems using the Internet are based on a “shopping cart” model allowing the selection of various items from an electronic catalog. The shopping cart model allows a purchaser to view items in an electronic catalog and select items for purchase by metaphorically adding the items to a shopping cart. When the purchaser is done selecting items, all of the items in the shopping cart are “checked out” (i.e., the order is submitted). The purchaser then typically provides order information, such as payment and shipment information. Often, such systems also allow a user to check the status of a previously placed order.
Many prior art enhancements to such systems have generally been directed to increasing ease of use by the user, i.e., by reducing the number of pages that must be viewed, or the number of cursor manipulations required to be performed to complete the transaction. In such systems, each user is assigned a unique user ID. This user ID is sent to the server, e.g., manually entered or retrieved from a cookie placed on the client computer system, and can be used to access purchaser-specific information, e.g., in a database on the server. However, implementing a unique user ID in a corporate requisition environment can in some instances be burdensome for system administrator, particularly where there is a large number of employees, or where a high turn over rate of employees requires new accounts to be continually set up by an administrator.
An application architecture that is becoming widely used, particularly in the Internet environment, is the three-tier architecture. In this architecture, a client communicates requests to a server for data, software, and services, for example, and the server responds to the requests which may entail communication with a database management system for the storage and retrieval of persistent data. The three-tier architecture includes a database tier that includes a database server, an application or server tier that includes an application server and business logic (i.e., software application programs, functions, etc.), and a client tier. The application server responds to application requests (e.g., a request for a software applet, etc.) received from the client. The application server forwards data requests to the database server. An enterprise's application may involve all three tiers, as data that is used by the application may be stored in a database.
Conventionally, changes in an application, such as the addition of new forms of data or the revision of current forms of data, customization of the user interface, and so forth, often require that the client software and application software be rewritten to accommodate such changes. Usually, a software vendor will lack the additional time and resources to accommodate requests from its customers to create individual, customized versions of its application. However, a purchaser or user of a server application provided by the software vendor sometimes undertakes such changes to the application on its own. Since such changes to the application are not performed under the control of the software vendor, support and maintenance problem often arise for both the purchaser and the software vendor.
Accordingly, the present invention provides a server application having a standard application programming interface (API) which allows the purchaser of the server application to customize or create their own user interface which overcomes the above problems and others.